Philippe Lhoste <Phi### [at] gmxnet> wrote:
> Note: I have seen in the PoV-Ray VFAQ that binary format (it was for mesh
> files) was out of question

  It's not out of question. It's just difficult to make it so that it will
work without problems in any system where POV-Ray has been ported. The
biggest problem is endianess, and a minor problem is different floating
point formats (which is actually a major problem in the case that the
format is different; but I consider it minor here because virtually all
practical computers use the same floating point format).

  As for the binary povray format, it's not good to make a kludged format
which is just a pov-file in binary format. It just makes the files smaller,
without any other benefits.
  The correct way to go is the to change the POV-Ray parser completely.
It should work like perl: It first byte-codes the source file to memory
and then it interpets this byte code (the function parsing already does
this; it just needs to be extended to everything). The main reason for
doing this is speed: If the source has lots of loops, macros, etc, the
speed increase could be enormous compared to the current speed.
  After this is done, it should be easy to just make a raw dump of the
bytecode to a file. This file will then be the binary format. Reading
this file will then be extremely easy: Just read the entire file to memory
and start interpreting. This saves the parsing stage, which can be really
slow.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message